WHY

同事問，為什麼我前五天的index消失了。
我震驚，不應該啊。
開始漫長的查詢之路

NOTE

filebeat 重新上傳

直接看indices的內容，
真的沒有前幾天的資料，但文件還在，
那不然先把文件重傳回來好了。

filebeat靠registry底下的檔案(k8s內的路徑為/usr/share/filebeat/data/registry/filebeat/data.json，
來判斷這個文件有沒有讀取過，
所以將這個資料夾底下的檔案清空，重啟Pod，就會觸發強制重傳了。

rm -rvf /usr/share/filebeat/data/registry

題外話，然後因為前面的文件太多沒刪除，
導致elk的硬碟直接塞滿。

檢查index的ILM 有沒有生效

先確認ilm的政策正確，下面會列出全部的ilm，看是不是跟你想像的一樣。

GET /_ilm/policy?pretty
or
GET _ilm/policy/delete-bms-indices-after-7days?pretty

結果如下，
建立index時，會馬上進入到hot 的phases（根據min_age=0ms)，
然後14天後，會到delete的phases（min_age=14d)。

  "delete-bms-indices-after-7days": {
    "version": 4,
    "modified_date": "2024-10-23T08:49:16.681Z",
    "policy": {
      "phases": {
        "hot": {
          "min_age": "0ms",
          "actions": {
            "set_priority": {
              "priority": 100
            }
          }
        },
        "delete": {
          "min_age": "14d",
          "actions": {
            "delete": {
              "delete_searchable_snapshot": true
            }
          }
        }
      }
    }

再來看index的 ilm

GET /qa-game-cold-back-gamecoldtransdata-2024.12/_ilm/explain

內容如下，目前建立了5.23d，要到14d可能還要一陣子，
先放著之後看結果。

{
  "indices": {
    "qa-game-cold-back-gamecoldtransdata-2024.12": {
      "index": "qa-game-cold-back-gamecoldtransdata-2024.12",
      "managed": true,
      "policy": "delete-bms-indices-after-7days",
      "index_creation_date_millis": 1743131249510,
      "time_since_index_creation": "5.23d",
      "lifecycle_date_millis": 1743131249510,
      "age": "5.23d",
      "phase": "hot",
      "phase_time_millis": 1743131249629,
      "action": "complete",
      "action_time_millis": 1743131249829,
      "step": "complete",
      "step_time_millis": 1743131249829,
      "phase_execution": {
        "policy": "delete-bms-indices-after-7days",
        "phase_definition": {
          "min_age": "0ms",
          "actions": {
            "set_priority": {
              "priority": 100
            }
          }
        },
        "version": 4,
        "modified_date_in_millis": 1729673356681
      }
    }
  }
}

結論

突然靈光一閃，猜測有可能是因為index我是以月為單位留存的，
為什麼index不以天留存呢？因為以前曾經發生過shared數量太多，
導致機器卡住。
但刪除的天數是14天，
所以ilm執行時就直接將這個index刪掉。

未驗證

如果ILM更改很大，但舊的index沒有進入到新的階段，
讓ILM重新評估。

POST _ilm/run

如果還是沒成功，
手動將index推到新的phase

POST /<your-index>/_ilm/move
{
  "current_step": { "phase": "hot", "action": "complete", "name": "complete" },
  "next_step": { "phase": "delete", "action": "delete", "name": "delete" }
}